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BACKGROUND OF THE INVENTION 
20 The present invention relates in general to digital processing and more 

specifically to an application model for the use of dynamic computing environments in 
various phases of software lifecycle. 

In the past, software providers shrink-wrapped software in digital media, such 
as floppy disks or CD-ROMs, for distribution to customers. Thus, distribution involved one 
25 copy of the software per customer. 

With the arrival of the Internet, distribution by downloading was made 
possible, but software was still packaged as an entity that has to reach each individual 
customer. Thus, a new mode of software -the 'Web site' -was made available. The Web 
site is a limited abstraction of a client-server software model where the clients were now 
30 universal web clients, i.e., browsers, and the servers had limited and focused functionality, 
i.e., searching, messaging, transacting, etc. In this model, browsers did not depend on the 
specific software running on any web site or the specific service provided by any web site. 



Thus, the new distribution model for software was the exact reverse of the older model - all 
customers (virtually) travel to the web site to use the software instead of the software going to 
the customer(s). Therefore, a single copy of the server software was used for many 
customers (without distribution) and client software was available/applicable universally. 
5 This reversal entailed a fundamental shift in the underlying model of computation in that 
most data (search catalogs, emails, product catalogs) were generated and/or stored at the 
provider end and almost all of the computation happened at the provider end. This was 
different from the traditional model where all the data were generated and stored on the 
customer end and all the computation happened on the customer end. Even in the traditional 
,10 client-server setting, both the client and the server were typically located in the customer end. 

Q The maturity of Internet/Web software and the increased availability of 

Q 

>■ cheaper communication bandwidth have resulted in another model of software distribution: 

f: the Application Service Provider (ASP) model, also known as the 'Software as Service' 

W 

if} model. The model fills a continuum between the two models described above: software can 

H 5 be located completely at the provider end or can be modularized so that some parts are 

O located at the provider end and the rest at the customer end. In this model, data may be 

M 

f«! ; generated at the customer end, the provider end, or both. Additionally, computation may 

happen at either end or can be distributed in parts. Thus, either a single copy of the software 
p j may be used for many customers or each customer may receive a copy of some parts of the 
20 software. Also, computation may even be mobile, i.e., computation may be switched 

dynamically - back and forth - between the provider and customer ends. This implies on-the- 
fly distribution of copies of parts of the software to individual customers. 

The typical lifecycle of software includes the following phases: development, 
integration, testing, beta testing, beta deployment, staging, and deployment. Additionally, 
25 this list does not include phases like Requirements Analysis or Design that typically do not 
involve computing resources. Also, all these phases may not apply to all three of the 
software models discussed above and even when they do apply, they may be highly 
dissimilar in nature. For instance, staging is not a typical phase for shrink-wrapped software. 
As another example, deployment of shrink-wrapped software involves deployment in various 
30 customer environments while deployment of web-site software involves hosting in the 

provider environment, and further deployment of ASP software may involve a combination 
of both of these and infrastructure for enabling distributed/mobile computation. 

A given software model will entail a spectrum of computing needs and 
constraints to cover the various phases of the lifecycle. For instance, the development phase 
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of the lifecycle may need many copies of one type of configuration; while the testing phase 
may need one copy of many types of configurations. In order to meet the different needs of 
each phase of the lifecycle, a provider must manually set up the computing requirements for 
each phase. For example, in the development phase, many copies of the one type of 
configuration must be loaded onto a number of computers for development to be done. Once 
the development stage has been completed, the testing phase may require many types of 
configurations. The different configurations either need to be manually loaded onto the same 
computers used in the development stage or other computers with the desired configurations 
must be found and set up. 

The different requirements of each phase of the software lifecycle presents 
problems in relation to manpower, computing power, and flexibility. For example, 
administrators are needed to address the changing computing needs of each phase, 
p j Additionally, administrators physically set up the computers required for each phase. With 
regard to computing power, certain phases may require more powerful machines than other 
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s 1 5 phases, which may cause cost and space restrictions on a provider. For example, the testing 

cs 

\Jk phase may require the use of many workstations and the development phase may require the 
use of a personal computer. Because of the high cost of workstations, a provider may not be 
able to purchase an adequate number of workstations or may not be able to justify purchasing 
a large number of workstations for only one phase of the software lifecycle. Further, a 
20 provider is limited to using the actual machines that are present at the site of the stage of the 
lifecycle. Thus, new machines cannot be used during a stage without physically importing 
them into the site. 

The computing requirements of each phase may be different from other 
phases. Thus, moving from one phase to another results in reconfiguration of computing 
25 environments. The physical reconfiguration results in waste of manpower (i.e., systems 
administrators) and delays in the lifecycle itself. 

BRIEF SUMMARY OF THE INVENTION 
An application model for using Dynamic Computing Environments (DCEs) in 
30 a software lifecycle is provided by virtue of the present invention. 

In one embodiment, DCEs are used throughout phases of a software lifecycle. 
The DCE is configured through a remote user for a phase in the lifecycle. The DCE is then 
configured according to the command. The user then uses the DCE to fulfill the requirements 
of the phase. When the phase is completed, a command from the remote user is sent to 
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configure the DCE for another phase. Once the DCE is re-configured, the user uses the DCE 
to fulfill the requirements of the phase. 

All the computing resources that are used during the phases are located in the 
DCE. The user's computing resources are only used to communicate with the DCE. Thus, 
phases in the software lifecycle may be completed remotely using the DCE. 

In one embodiment, a method of using a dynamic computing environment 
("DCE") for a plurality of phases in a software lifecycle, wherein each phase in the plurality 
of phases in the software lifecycle include computing resource requirements. The method 
comprises: (a) sending a command to the DCE to allocate computing resource requirements 
for a phase in the plurality of phases; (b) configuring the DCE with the computing resource 
requirements for the phase; (c) performing the phase using the configured DCE; and (d) 
repeating steps (a) - (c) for the plurality of phases in the software lifecycle. 

A further understanding of the nature and advantages of the invention herein 
may be realized by reference of the remaining portions in the specifications and the attached 
drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates a USER1 PC, USER2 PC, and a dynamic computing 
environment ("DCE") according to one embodiment; 

Fig. 2 illustrates a method for the software development stage using the DCE 
according to one embodiment; 

FIG. 3 illustrates a method of using DCE for the integration phase according 
to one embodiment; 

FIG. 4 illustrates a method of using the DCE for the testing phase according to 
one embodiment; 

FIG. 5 illustrates a method of using the DCE for the beta testing phase 
according to one embodiment; 

FIG. 6 illustrates a method of using the DCE for the staging phase according 
to one embodiment; and 

FIG. 7 illustrates a method of using the DCE for the deployment stage 
according to one embodiment. 
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DETAILED DESCRIPTION OF THE INVENTION 
One embodiment of the present invention allows fast, efficient selection and 
configuration of processing networks, which can then be accessed and managed remotely. 
The processing network is referred to as a system including "resources." A system resource 
5 is any hardware, software, or communication components in the system. For example, 
discrete hardware devices include processing platforms, such as computers or processors, 
mobile/laptop computers, embedded computing devices, hand-held computers, personal 
digital assistants, point-of-sale terminals, smart-card devices, storage devices, data 
transmission and routing hardware etc., without limitation. Additionally, computer 
10 peripherals such as monitors, input/output devices, disk drives, manufacturing devices, or any 
y device capable of responding to, handling, transferring or interacting with digital data are also 
|3 resources. Software, or any other form of instruction, is executed by processors in the system 
jp and is also a type of resource. Finally, communication resources are also part of the system 
PfJ such as a digital network's hardware including the network's configuration and topology, 

t§. where control of the network is provided by software and/ or hardware. Additionally, the 

.0 . ... 

H network may be based on wired connections or wireless connections. For instance, the 

?f network hardware and software may be based on Bluetooth wireless standards. 

M For example, a processing network of a general consumer might include a 

ST"*?' 

n PDA and a cell phone, each connected by wireless channels to a single personal computer, 

II) which in turn is connected to an email server at a remote location through the Internet. As 

another example, a processing network might include a personal computer running Microsoft 
Windows 98 operating system, a lap-top computer running Linux operating system, and 
another personal computer running Windows NT operating system along with router and 
firewall software, wherein all three computers are connected using a local Ethernet hub, and 

25 the router software routes connections to the Internet. 

According to an embodiment of the present invention, the resources for such a 
processing network are fully selectable and allocable by a system architect. In a specific 
embodiment, a primary company, Jareva Technologies, Inc.® provides proprietary 
technology to a system architect for designing a system by allocating resources and 

30 specifying how the resources are to be used. The system architect may be an individual, 

corporate entity, etc. The system is referred to as an "environment" - or more specifically as 
a "computing environment" and the primary provider of such an environment is referred to as 
an Environment Service Provider (ESP). A typical system architect is referred to as the 
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"customer." The primary provider obtains revenue for providing the resources and the tools 
to easily select, allocate, configure and run the environment. 

A specific embodiment of the present invention allows fast allocation and 
configuration of resources such that different environments can be created from the same 

5 resources within minutes, or even seconds. This allows "time sharing" of overall resources 
so that a first environment may be "alive" or operative for a time period defined by the 
system architect (e.g., daily two-hour slot), followed by second, third and fourth 
environments being instantly created for the next four hours for three different customers, and 
so on. After a time period expires, such environments might either manually or automatically 
10 de-allocate such resources. Because these "computing environments" may be dynamically 
configured and re-configured out of the same set of resources, they will also be referred to as 

C3 "Dynamic Computing Environments". 

1; In particular, environments without any computing devices i.e., environments 

W made only of networks, will also be referred to as "virtual networked environments" or 
lit simply as "virtual networks". 

L A specific embodiment allows customers to create a computing environment 

f k from a remotely-accessible user interface such as a web page on the Internet. Thus, the 
Ik customer can create, modify and operate the environment from anywhere in the world. Since 
H the resources, in turn, can communicate over networks, including the Internet, this approach 
20 eliminates the cost of shipping hardware and software. Hardware and software designers, 
programmers, testers or other personnel using an environment according to the present 
invention can, similarly, be located anywhere in the world such that labor costs are 
optimized. 

The creation of dynamic computing environments ("DCE") is automatic. For 
25 example, a customer can request a web-site simulator using twelve web-page servers on a 
Microsoft® NT platform, two disk arrays at a specific bandwidth and storage capacity, two 
caching servers and 200 clients running Netscape Navigator™ under Microsoft Windows® 
2000 using Pentium III™ processors at under 800 MHz. Such an environment is created and 
destroyed, and even re-created automatically, without human intervention each time. Unlike 
30 the conventional computing infrastructure, according to an embodiment of the present 
invention there is no need to physically couple or de-couple, each physical machine or 
resource to each other upon adding or removing such resources. There is no need to set-up 
Internet Protocol (IP) addresses or other network settings, or install operating systems and 
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associated application programs on one or more physical machines. All such activities on a 

DCE can be performed automatically without user intervention. 

According to an embodiment of the present invention, the DCE is a virtual 

computing system including a network comprising a number of distinct types of machines 
5 and a network connecting them. For example, a system architect might require a DCE to 

include a Sun Sparc running a certain version of Solaris O/S coupled to a Linux machine. 

The present invention enables the separation of the activity of designing a DCE, from the 

activity of actually creating the DCE. Designing a DCE includes choosing the specific 

hardware, choosing the operating systems or other software, and choosing the specific 
10 interconnections, etc. Creating a DCE includes allocating the resources, installing the 
M operating systems and other software, etc. Furthermore, embodiments of the present 
O invention automate the process of creating the DCE. A DCE for which resources have not 

been allocated yet will also be referred to as a virtual computing environment. Similarly, a 
pj* computing device (or a subnet) that is part of a DCE will also be referred to as a virtual 

W computing device (or a virtual subnet), if the required resources for the computing device (or 

O 

3 the subnet) have not been allocated yet. 

n 

rf An embodiment of the present invention provides a framework that enables 

fPfg 

!■* configuring, and provisioning DCEs remotely. Configuring a DCE involves choosing the 
gj. resources and their interconnections. Embodiments of the present invention support 
f<§ operations for making such design choices through appropriate programmable interfaces. The 
interfaces can be used interactively through a graphical user interface such as a web page or 
non-interactively through a program script. Provisioning a DCE involves allocation of 
physical resources required for a DCE to function. Embodiments of the present invention 
manages the physical resources needed for provisioning DCEs and supports operations for 
25 allocating/de-allocating these resources. In one embodiment of the present invention, the 
framework for provisioning DCEs is implemented as a distributed system consisting of 
different software programs running on different computers and networking hardware. In a 
further embodiment, the present invention permits "virtual" hosting of dynamic computing 
environments. As used herein, the term "virtual" specifies that neither the requisite devices 
30 nor the network need to be physically accessible to users. Further, in accordance with this 
embodiment, the hosting process may be initiated or terminated by users at will, from any 
geographic location. Thus the administrative framework allows users to remotely configure 
and provision DCEs. 
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A further understanding of embodiments of the present invention will be 
gained with reference to the diagrams and the descriptions that follow. 

In FIG. 1, a USER1 PC, USER2 PC, and a dynamic computing environment 
("DCE") 104 is shown. The USER1, USER2, and DCE are interconnected through a digital 
5 network 120, such as the Internet. 

DCE 104 includes any number, type, and configuration of hardware 
components and software processes. For example, a user, or a group of users, may be 
allocated an International Business Machines (IBM) compatible PC (such as PC D) having an 
Intel processor, running a Microsoft operating system, having random-access memory 
10 (RAM), hard disk storage, etc. Software process 102 is also running within the PC of DCE 
K 1 04. Note that any arbitrary user may be allocated any combination of resources. 
O USER2 may be local to the DCE but will typically be located in a remote 

51 location from the physical DCE and communicates with the allocated resources via a digital 
!}j network such as Internet 120. Communications handler 122 can be dedicated software to 
18 allow USER2 to interact with the allocated resources and with software process 102. 
pi Communications handler 122 can also be, e.g., a web browser, operating system, or other 
■!*■ means of interfacing and control. In some cases, communications handler 122 is not needed. 
U - For example, USER2 can communicate with the DCE via communications hardware and 
|| software at the DCE (not shown in FIG. 1) so that USER2 may not even need a PC but can 
20 use a "dumb" terminal, or limited device such as a personal digital assistant (PDA), palmtop 
computer, web-enabled cell phone, etc. 

USER1 can be local to the DCE but will typically be located in a remote 
location from the physical DCE and communicates with the allocated resources via a digital 
network such as Internet 120. USER1 includes a communications handler 124, which can 
25 include the same properties as communications handler 122. USER1 can also include the 

same properties as described above for USER2. Additionally, USER1 can be local to USER2 
or can be located in a remote location from the physical USER2 PC. 

Software process 102 can be any type of application program, applet, 
operating system, plug-in, user-interface controller, or other process. Also, more than one 
30 user can use the allocated resources of the DCE at one time. 

USER1 and/or USER2 are able to execute, or have other interaction with, 
software process 102. However, software process 102 is not resident at USER1 or USER2's 
PC. Instead, software process 102 resides in DCE 104. USER1 can also contain software 
processes allowing USER1 to allocate resources in the DCE. For example, a user interface as 
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disclosed in "User Interface for Dynamic Computing Environment Using Allocateable 
Resources" Serial No. 09/663,252 filed on September 15, 2000 and U.S. Non-Provisional 
Patent Application entitled "System for Configuration of Dynamic Computing Environments 
Using a Visual Interface" Serial No. 09/662,990 filed on September 15, 2000 can be used by 
5 USER1 to allocate resources. USER1 can then allocate and configure various resources for 
USER2. Additionally, USER1 can re-allocate and re-configure the various resources when 
needs change or different applications need to be run. Also, it should be understood that 
USER2 can also allocate resources in the DCE. Further, control to allocate and configure 
resources can be switched between USER1 and USER2. Also, either USER1 or USER2 can 
1 0 have priority in allocating and configuring resources. Thus, the user that has priority can 
hk send a command overriding any other user's control to allocate resources. 
M Once the resources have been allocated, USER1 and/or USER2 can interact 

45 with software process 1 02. For example, USER2 can interact with software process 1 02 and 
2] receive information related to the interaction. USER2 can also modify the information and 
ijj further interact with software process 102. Additionally, USER1 may wish to monitor or 

■> control USER2's interaction with the software process 102. USER1 can then send a 

O 

LI command to cause interface and control information to be transferred to USERl's PC. In 
f 4 other words, USER1 may receive the same information or view the same screen as shown on 
O USER2's PC. USER1 can also send a command limiting USER2's control, or access, to 
IS software process 102. For example, USER2 may be only given viewing rights and not 

control rights. In contrast, USER2 can also send a command requesting control or access of 
the software process 102. In order to avoid conflicts, a priority system can be set up where 
either USER1 or USER2 will receive control or access over the other user. For example, a 
command from USER1 would cause USER2 to lose control until USER1 signaled control 
25 should be given back to USER2. Thus, control of the software process 102 and control of 
which user PC can modify the information received is enabled. 

Therefore, USER1 and USER2 can gain control over the identical resources. 
This eliminates inherent problems caused by having different users operating different 
computing systems while trying to access or share the same resource. Additionally, users 
30 other than USER1 and USER2 may be included. 

The use of dynamic computing environments enables rapid provisioning of 
computing infrastructure to meet the computing needs of various phases of software lifecycle. 
In each phase of the cycle, resources may be automatically allocated in the DCE depending 
on the various needs of the stage. Users participating in each stage can access the 
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environment through a user interface, such as a web browser, and use the allocated resources 
throughout each stage. Each user may use the same computer throughout the process and 
changes to the allocated resources are accomplished seamlessly without affecting the user. 
Additionally, each stage of the software lifecycle may completed using the same DCE for 
5 multiple software models, such as the shrinkwrap, web site, or ASP models. 

In one embodiment, some or all of the following phases may be part of a 
software lifecycle for a software lifecycle, such as the shrinkwrap, web site, or ASP models: 
development, integration, testing, beta testing, beta deployment, staging, and deployment. 

During the software development phase, usage of computing resources goes 
10 through short iterations of interactive activity (editing), followed by typically CPU intensive 
M; activity (compilation and execution). This phase of the lifecycle and the computing 
?j requirements are similar across the different models of the software lifecycle. Typical 
45 computing requirements for this phase include multiple copies of different configurations of 
fij hardware/software combinations. For example, all developers of a software organization 
ijjlf may use Linux operating system on a x86 architecture as the development platform, 
a Dynamic computing environments optimize the resource usage based on the individual 
tt activities. For instance, a developer may use one system for editing and use one or more 
F k other systems for compilation and execution even though none of these systems are reserved 
El for or locally available to that developer. 

2(3 Fig. 2 illustrates a method for using DCE 104 for the software development 

stage according to one embodiment. A developer, such as USER1, may use DCE 104 to 
complete all tasks during the development phase. Additionally, all of the development tasks 
may be accomplished simultaneously. For example, in step S200, a command is sent to 
automatically allocate resources, such as PC A, with a first hardware/software configuration 

25 for a first task, such as editing. The computing resources are then configured in DCE 104 
(S201). USER1 may then direct PC A to perform tasks, such as edit or develop code, from 
the user interface located on USER1 's PC (S202). 

If a second configuration is needed (S203), a command may be sent to 
automatically allocate and configure a second PC, such as PC B, with a second configuration 

30 that would be used for a second task, such as for the compilation and execution of developed 
code (S204). USER1 may then direct PC B from the user interface to perform tasks, such as 
compiling or executing code. 

Thus, using the configured PC's, USER1 may edit or develop code while 
compiling or executing code. These tasks may be completed by USER1 without imposing 



any computing requirements on USER1 ? s PC. Unlike prior art, where the system resources 
of the computers USER1 's PC are being used, all computing is done on the allocated 
resources in DCE 104 while USER1 interacts with DCE 104 through a user interface. 
Additionally, USER1 is not restricted by space requirements needed for multiple systems. 
Further, USER1 's PC is not loaded down by the tasks being completed by PCs A or B. 
Certain tasks, such as compilation, may use up almost all of a computers processing power 
and thus, USER1 may not be able to further develop on a computer that is compiling code. 
However, using DCE 104, USERl's computer is still available for development purposes and 
only the remote computers PC's A and B processing power are being used. 

During the integration phase, different parts of the software are assembled 
together into one package. Computing requirements for this phase include multiple copies of 
different configurations of hardware/software combinations. Software is typically developed 
in independent modules by different developers. But the developers need to mutually agree 
upon common interfaces between these modules so that these modules may function 
collectively and interact with each other when they are connected. Thus, the integration 
phase starts out with a collection of modules and results in a fully functioning software. 

For instance, a three-tier software system typically includes an application 
server, a web server, and a client. Prior to integration, the application server, the web server 
and the web client have been developed independently based on interfaces and protocols 
mutually agreed upon among developers. In this instance, integration may involve ensuring: 
that a client can send a request for a specific high level task to the web server; that the web 
server will translate this request to one or more actions to be performed on the application 
server and send a request for each of these actions; the application server will perform these 
actions, and may access and/or update a database as part of these actions, and will send the 
results to the web server where the web server will compose these responses and report the 
necessary information to the client; and the client will then present the information in a 
suitable form to the user. 

Each of the three components may be configured from a set of options. Using 
the same terminal as used in the development stage, USER1 sends a command to allocate 
resources in DCE 104 with the required hardware/software combinations for the integration 
phase. For example, in a specific embodiment, USER1 may configure: an application server 
in DCE 104 with an Informix database running either on a Solaris™ server or on a Linux 
server; a web server in DCE 104 with either be a Linux system hosting an Apache™ web 
server or a Microsoft Windows NT™ system hosting an IIS™ web server; and a client in 
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DCE 104 with an Active-X™ component either in a Microsoft Windows 95™ system or in a 
Microsoft Windows 98™ system. Thus, all integration may be controlled by USER1 with 
different configurations being allocated as needs change. 

FIG. 3 illustrates a method of integration using DCE 104 according to one 
5 embodiment. In step S300, USER1 determines the different configurations of 

hardware/software that are needed for the stage. A command is then sent to automatically 
allocate resources in DCE 104 to realize the desired configurations (S302). DCE 104 is then 
configured (S303). Integration of the software is then performed using DCE 104 through 
USER1 's PC (S304). During integration, USER1 may decide that different configurations 
10 are needed (S306). If so, a command is sent to re-provision DCE 104 to represent the new 

jU configurations (S308). DCE 104 is then re-configured (S3 10), and the method re-iterates to 

Q 

r ; step S304 where integration tasks are again performed. The method ends if different 

*f | configurations at not needed. 

T4 Using dynamic computing environments for the integration phase enables 

"I 5 S 

uniform access to all these systems through USER1 's web browser. Most of these 
requirements may be "shorter-term" needs when compared to the development phase, 
j* Because dynamic computing environments enable rapid provisioning or re-provisioning of 
infrastructure upon a command from a user, DCE's are suited for meeting the needs of the 
integration phase. 

m 

20 Dynamic computing environments also enable allocation of resources during 

the testing phase of the software lifecycle, where requirements may include clean 
configurations and crash-and-burn environments. FIG. 4 illustrates a method of using DCE 
104 for the testing phase according to one embodiment. In step S400, the resources that need 
to be allocated are determined. Typically, testing is done on a wide range of computing 

25 devices, which run different operating systems and software. Each of these 'configurations' 
has to be defined in terms of the type of the component resource (hardware or software), the 
vendor, the version, etc. For example, in a specific embodiment, in the integration scenario 
described above, testing the web server component may involve the configurations (a) and (b) 
listed below: 

30 (a) all combinations of the following - one of RedHat Linux™ version 

5.2, RedHat Linux™ version 6.0, or TurboLinux™ version 6.0 
hosting one of Apache™ web server with the cgi-bin module or 
Apache™ web server with the Java™ servlets module; and 
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(b) IIS™ server running on one of Windows NT™ 4.0 with service pack 
3, or Windows NT™ 4.0 with service pack 5. 

In addition, special testing software and test-suites may be included in the 
configuration of the systems used in this phase. 

In step S402, a command is sent from USER1 to allocate the determined 
resources in DCE 104. In step S403, DCE 104 is configured. In step S404, the software is 
tested using the configured resources. During a sequence of tests, the environment may get 
corrupted or the system may crash. Consequently, the testers have to start with a fresh copy 
of the configuration for each cycle of testing. Thus, if errors occurred (S406), the same 
configuration that crashed is automatically re-provisioned with a clean environment (S408). 
The method reiterates to step S404 software is tested again. If no errors occur, the method 
ends. 

Accordingly, dynamic computing environments enable fast and easy 
configuration of computing resources required for testing. Also, DCEs enable replication, 
saving, and restoring of these configurations, which reduces the tedium of repetition 
involved. 

Additionally, testing usually involves multiple aspects of software, such as 
compatibility, functionality, usability, and scalability. Testing schemes and systems needed 
may also depend on the model of software. Dynamic computing environments provide a 
comprehensive platform for all testing needs of an organization. Also, DCEs free an 
organization from owning and maintaining the systems at all times when they are used only 
for testing. 

The beta testing phase may involve testing done by personnel outside the 
development organization before a software system is deployed. Similarly, beta deployment 
may refer to deployment for the purpose of evaluation of software by personnel possibly 
outside the development organization. In the shrink-wrap model, this involves downloads or 
installations by individuals who are participating in the process. Although downloads and 
installations may have to be tested as part of the process, these may distract beta testers or 
beta customers from other aspects of testing and usage. In addition, even if beta testers are 
willing to go through downloads and installation, they may not be willing to risk corrupting 
their storage or configuration of their own systems to test software developed by others. 
Therefore, dynamic computing environments may then be used as a channel for beta testing 
and deployment. 
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FIG. 5 illustrates a method of beta testing and deployment according to one 
embodiment. In step S500, a first beta tester, such as USER1, sends a command to 
automatically install a software/hardware configuration to be tested on DCE 104. The 
software is then automatically installed in DCE 104 (S502). The first beta tester then tests 
5 the software from the beta testers terminal (S504). Thus, the beta tester can beta test the 
software without installing any software on their own computer. Once the beta tester is 
through testing, the software may be returned to storage or uninstalled from the allocated 
resources (S506). Thus, the allocated resources can be used for other purposes. Typically, 
proper beta testing involves testing the software with many different users. Therefore, if 
10 another user, such as USER2 or another individual using the USER1 terminal, desires to beta 
test the software (S508), and reiterates to step S500 where a command is sent to DCE 104 to 
Ct automatically install the same or another software/hardware configuration on DCE 104. The 
method ends when there are no other beta testers. 

Accordingly, a software development organization may use DCE 104 to 
ES provide systems for individual testers or customers on demand. This reduces the ownership 
q and maintenance cost of computing resources. Additionally, dynamic computing 

environments remove the location-dependency aspect of the shrink-wrap software model, 
U elevating the model to be on par with the ASP model or web site model in terms of location- 
m\ agnostic access. 

20 The phase of staging usually applies to the web site model and the ASP model; 

however, the phase is not limited to the web site and ASP models. The phase usually serves 
different purposes, such as scalability testing, transiting from an existing version to a new 
version, and integrating software with the rest of the provider environment. FIG. 6 illustrates 
a method of using DCE 104 for the staging phase according to one embodiment. In step 

25 S600, USER1 sends a command to automatically install the software/hardware configuration 
on DCE 104. In step S601, the software/hardware configuration is installed and configured 
on DCE 104. Then, a portion of users of the old software can be directed to the new software 
(S602). The new software is then tested, monitored, etc. (S604). If the new software is not 
working properly (S606), the software may be modified or the process may go automatically 

30 install entirely new software on the DCE (S608). The method then reiterates to step S604 for 
re-testing. 

If the new software is working properly, the old system may be replaced with 
the now tested new system (S610). In order to seamlessly transfer the new software to the 
new software site, all users can be directed to the functioning new software while the old 
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software is being replaced (S612). Once the new software is installed, the users can be re- 
directed back to the old system, which has the new software installed on it (S614). 

An example of the above process may be when a web site replaces its search 
engine software with a new version and a new URL may be required to access the web site. 
5 Because links to the search engine may be scattered all across the web, the replacement 
cannot be instantaneous. The web site may stage the new software and then seamlessly 
redirect a part of its users to the new software until the old software is completely replaced. 
This will also enable the web site to integrate the search software with the rest of the web 
site. Also, staging by itself may be a graded process so that new software eventually replaces 
10 existing software. During the process of staging, computing environments have to be 

switched effectively from using one set of software to another. In addition, the web site may 
9 want to enforce some level of isolation between these sets for maintenance and tracking 

purposes. The isolation may result in additional infrastructure and manpower for 
T & maintenance, both of which will be redundant after the staging phase. 
|g Dynamic computing environments eliminate the redundancy by catering to 

J* short-term needs effectively. In addition, if a large organization uses specialized software 
F: 1 and system settings for staging, then dynamic computing environments help save the settings 
U as special configurations that may be restored on demand. Thus, dynamic computing 
%. environments help an organization to perform staging more often and more effectively 
jy because of the reduced cost and effort. 

The deployment phase may vary between the shrink-wrap, ASP, and web site 
models. For example, in the shrink-wrap model, the deployment phase is not usually owned 
by the organization developing and selling the software. However, in the web site and the 
ASP models, the deployment phase is owned by the organization responsible for 
25 development, sales, or both. For example, an organization hosting or deploying the web 
service may choose to deploy a plurality of copies of the same configuration (hardware, 
software, and network access). Thus, the deployment requires several copies of one type of 
web service configuration (e.g., x86 computers running Linux operating system and the web 
service software). In prior art, the multiple copies have to be installed manually because 
30 there is no easy way to replicate a configuration. This may be acceptable for initial 

deployment. However, the deployment phase also requires constant updates (for bug fixes or 
performance updates or other improvements to the software). All these updates also have to 
be consistently replicated on all the copies. Prior art systems use manual efforts for 
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replication, which require man power and also results in delays and down-times for the 
service. 

FIG. 7 illustrates a method of using a DCE for the deployment stage according 
to one embodiment. In step S700, a command is sent from USER1 to allocate computing 
resources for the deployment stage in DCE 104. For example, multiple copies of one 
configuration may be allocated for a software program. The multiple copies may be allocated 
on multiple PCs, such as PC A, PC B, etc. In step S702, the computing resources are 
configured in DCE 104. In step S704, users may access DCE 104 remotely and test the 
software and computing resources. 

If updates are required after testing (S706), a command is sent to allocate 
computing resources with updated or fixed software configurations (S708). In step S710, the 
computing resources are configured with the updated software configurations. The method 
then reiterates to step S704 where the software and computing resources are tested again. If 
updates are not required, the method ends. 

Thus, a system enabling automatic configuration and re-configuration of 
computing environments increases the utilization of computing infrastructure and reduces the 
transition time between different phases of the software lifecycle is provided by embodiments 
of the present invention. 

The above description is illustrative but not restrictive. Many variations of the 
invention will become apparent to those skilled in the art upon review of the disclosure. The 
scope of the invention should, therefore, be determined not with reference to the above 
description, but instead should be determined with reference to the pending claims along with 
their full scope or equivalence. 
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